Three tools that did not talk to each other.

Service teams, including MSPs, call centers, and NOCs, work across three separate systems: ticketing, where work gets assigned; a phone system, where calls come in; and team chat, where updates go. None of them know about each other. A worker focused on a ticket still gets pulled into incoming calls unless someone manually removes them from the queue. When they finish, nobody puts them back. Managers answering “who is available to take this call right now” have to check three systems, or ping people and wait.

This workflow showed up the same way across multiple service operations. The individual tools were fine on their own. The gap was the connective layer between them. The data needed to answer “who is available” already existed somewhere. Nobody had assembled it into a single view.

A service-operations dashboard and decision framework designed to reconcile rep activity across HaloITSM, RingCentral, and Slack. It translates system signals into clear rep states, routing eligibility, and manager exceptions, with every status change logged and searchable. It is a connective layer on top of the existing stack, not a replacement for it. Managers keep the context and authority to assign work, handle exceptions, and override the system when frontline reality requires it.

This is now a contracted engagement. A managed service provider is running it as a fixed-fee production pilot: a five-week build across discovery and integration validation, implementation, and user acceptance testing, deployed to a defined pilot group.

Each phase ends at a go/no-go checkpoint, so the work can stop at a natural boundary rather than running past the point of value. The client owns the result: full documentation, architecture overview, troubleshooting guide, and a runbook, so their team can support it without me.